Reviewing files that changed from the base of the PR and between cbddb8d and 34c5ac0.

• packages/dapi-grpc/clients/platform/v0/nodejs/platform_protoc.js (89 hunks)
• packages/dapi-grpc/clients/platform/v0/web/platform_pb.d.ts (38 hunks)
• packages/dapi-grpc/clients/platform/v0/web/platform_pb.js (89 hunks)
• packages/dapi-grpc/protos/platform/v0/platform.proto (18 hunks)
• packages/js-dapi-client/lib/SimplifiedMasternodeListProvider/createMasternodeListStreamFactory.js (1 hunks)
• packages/js-dapi-client/lib/methods/core/subscribeToMasternodeListFactory.js (1 hunks)
• packages/js-dapi-client/lib/methods/platform/getDataContractHistory/DataContractHistoryEntry.js (1 hunks)
• packages/js-dapi-client/lib/methods/platform/getDataContractHistory/GetDataContractHistoryResponse.js (3 hunks)
• packages/js-dapi-client/lib/methods/platform/getDataContractHistory/getDataContractHistoryFactory.js (2 hunks)
• packages/js-dapi-client/lib/methods/platform/getEpochsInfo/EpochInfo.js (3 hunks)
• packages/js-dapi-client/lib/methods/platform/getEpochsInfo/GetEpochsInfoResponse.js (1 hunks)
• packages/js-dapi-client/lib/methods/platform/getIdentityBalance/GetIdentityBalanceResponse.js (3 hunks)
• packages/js-dapi-client/lib/methods/platform/getIdentityContractNonce/GetIdentityContractNonceResponse.js (3 hunks)
• packages/js-dapi-client/lib/methods/platform/getIdentityNonce/GetIdentityNonceResponse.js (3 hunks)
• packages/js-dapi-client/lib/methods/platform/getStatus/ChainStatus.js (1 hunks)
• packages/js-dapi-client/lib/methods/platform/getStatus/GetStatusResponse.js (1 hunks)
• packages/js-dapi-client/lib/methods/platform/getStatus/NetworkStatus.js (1 hunks)
• packages/js-dapi-client/lib/methods/platform/getStatus/NodeStatus.js (1 hunks)
• packages/js-dapi-client/lib/methods/platform/getStatus/StateSyncStatus.js (1 hunks)
• packages/js-dapi-client/lib/methods/platform/getStatus/TimeStatus.js (1 hunks)
• packages/js-dapi-client/lib/methods/platform/getStatus/VersionStatus.js (1 hunks)
• packages/js-dapi-client/lib/methods/platform/getStatus/getStatusFactory.js (2 hunks)
• packages/js-dapi-client/lib/methods/platform/response/AbstractResponse.js (1 hunks)
• packages/js-dapi-client/lib/methods/platform/response/Metadata.js (2 hunks)
• packages/js-dapi-client/lib/test/fixtures/getMetadataFixture.js (1 hunks)
• packages/js-dapi-client/lib/test/fixtures/getStatusFixture.js (1 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getDataContract/GetDataContractResponse.spec.js (4 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getDataContract/getDataContractFactory.spec.js (2 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getDataContractHistory/GetDataContractHistoryResponse.spec.js (8 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getDataContractHistory/getDataContractHistoryFactory.spec.js (3 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getDocuments/GetDocumentsResponse.spec.js (3 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getDocuments/getDocumentsFactory.spec.js (3 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getEpochsInfo/GetEpochsInfoResponse.spec.js (3 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getEpochsInfo/getEpochsInfoFactory.spec.js (3 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getIdentitiesContractKeys/GetIdentitiesContractKeysResponse.spec.js (3 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getIdentitiesContractKeys/getIdentitiesContractKeysFactory.spec.js (2 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getIdentity/GetIdentityResponse.spec.js (2 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getIdentity/getIdentityFactory.spec.js (2 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getIdentityBalance/GetIdentityBalanceResponse.spec.js (2 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getIdentityBalance/getIdentityBalanceFactory.spec.js (3 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getIdentityByPublicKeyHash/GetIdentityByPublicKeyHashResponse.spec.js (2 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getIdentityByPublicKeyHash/getIdentityByPublicKeyHashFactory.spec.js (2 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getIdentityContractNonce/GetIdentityContractNonce.spec.js (2 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getIdentityContractNonce/getIdentityContractNonceFactory.spec.js (3 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getIdentityKeys/GetIdentityKeys.spec.js (1 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getIdentityKeys/getIdentityKeysFactory.spec.js (2 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getIdentityNonce/GetIdentityNonce.spec.js (2 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getIdentityNonce/getIdentityNonceFactory.spec.js (3 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getProtocolVersionUpgradeState/GetProtocolVersionUpgradeStateResponse.spec.js (1 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getProtocolVersionUpgradeState/getProtocolVersionUpgradeStateFactory.spec.js (2 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getProtocolVersionUpgradeVoteStatus/GetProtocolVersionUpgradeVoteStatusResponse.spec.js (1 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getProtocolVersionUpgradeVoteStatus/getProtocolVersionUpgradeVoteStatusFactory.spec.js (2 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getStatus/GetStatusResponse.spec.js (1 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getStatus/getStatusFactory.spec.js (1 hunks)
• packages/js-dapi-client/test/unit/methods/platform/waitForStateTransitionResult/waitForStateTransitionResultFactory.spec.js (3 hunks)
• packages/js-dash-sdk/src/SDK/Client/Platform/Fetcher/Fetcher.ts (1 hunks)
• packages/js-dash-sdk/src/SDK/Client/Platform/NonceManager/NonceManager.spec.ts (3 hunks)
• packages/js-dash-sdk/src/SDK/Client/Platform/NonceManager/NonceManager.ts (6 hunks)
• packages/js-dash-sdk/src/SDK/Client/Platform/methods/contracts/get.ts (1 hunks)
• packages/js-dash-sdk/src/SDK/Client/Platform/methods/contracts/history.ts (1 hunks)
• packages/js-dash-sdk/src/SDK/Client/Platform/methods/contracts/update.ts (1 hunks)
• packages/js-dash-sdk/src/SDK/Client/Platform/methods/documents/get.ts (1 hunks)
• packages/js-dash-sdk/src/SDK/Client/Platform/methods/identities/get.ts (1 hunks)
• packages/js-dash-sdk/tsconfig.json (1 hunks)
• packages/wasm-dpp/src/data_contract/data_contract.rs (1 hunks)
• packages/wasm-dpp/src/document/document_facade.rs (1 hunks)
• packages/wasm-dpp/src/document/factory.rs (1 hunks)
• packages/wasm-dpp/src/document/state_transition/document_batch_transition/document_transition/mod.rs (2 hunks)
• packages/wasm-dpp/src/document/state_transition/document_batch_transition/mod.rs (1 hunks)
• packages/wasm-dpp/src/errors/consensus/fee/balance_is_not_enough_error.rs (1 hunks)
• packages/wasm-dpp/src/identity/identity.rs (1 hunks)
• packages/wasm-dpp/src/identity/state_transition/identity_credit_transfer_transition/transition.rs (3 hunks)
• packages/wasm-dpp/src/metadata.rs (2 hunks)

• packages/js-dapi-client/lib/SimplifiedMasternodeListProvider/createMasternodeListStreamFactory.js
• packages/js-dash-sdk/src/SDK/Client/Platform/methods/documents/get.ts
• packages/wasm-dpp/src/document/document_facade.rs

packages/js-dapi-client/lib/methods/platform/getStatus/NetworkStatus.js (2)

13-32: LGTM! Well-documented getter methods.

The getter methods are consistently named, well-documented with JSDoc, and correctly implemented.

---

34-35: LGTM! Correct module export.

The class is properly exported.

packages/js-dapi-client/lib/methods/platform/getIdentityContractNonce/GetIdentityContractNonceResponse.js (2)

4-4: Verify if the 40-bit bitmask is sufficient.

The bitmask 0xFFFFFFFFFF only covers 40 bits, which might be insufficient for filtering u64 values that require 64 bits.

Please confirm if this is intentional or if it should be updated to 0xFFFFFFFFFFFFFFFF for full u64 coverage.

---

19-23: LGTM!

The return type update is consistent with the BigInt changes.

packages/js-dapi-client/lib/methods/platform/getEpochsInfo/GetEpochsInfoResponse.js (1)

44-44: LGTM! Converting to BigInt prevents precision loss.

The conversion of firstBlockHeight and startTime to BigInt is appropriate for handling large numeric values without precision loss.

Please ensure that:

1. The EpochInfo constructor has been updated to handle BigInt parameters
2. Tests have been updated to work with BigInt values
3. Consider if feeMultiplier (line 47) should also be converted to BigInt

Also applies to: 46-46

✅ Verification successful

BigInt Conversions Verified

• The conversion of epoch.getFirstBlockHeight() and epoch.getStartTime() to BigInt in the response is appropriate, and the EpochInfo constructor (as seen in its JSDoc) now correctly accepts BigInt values for these fields.
• No explicit test files for EpochInfo were found with the search pattern; please verify that any tests covering epoch metadata are updated to work with BigInt.
• Additionally, consider if the feeMultiplier (at line 47) should also be converted to BigInt, depending on its precision requirements.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check if EpochInfo class and tests have been updated for BigInt

# Find EpochInfo class definition
echo "Checking EpochInfo class definition:"
rg -A 10 "class EpochInfo" packages/js-dapi-client/

# Find related test files
echo -e "\nChecking test files:"
fd "EpochInfo.*spec" packages/js-dapi-client/

Length of output: 1358

packages/dapi-grpc/clients/platform/v0/nodejs/platform_protoc.js (87)

4667-4670: Switch from numeric to string fields is correct to preserve 64-bit integer precision.

---

4710-4713: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

4722-4725: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

4763-4764: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

4784-4785: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

4809-4821: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

4863-4875: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

7911-7911: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

7951-7951: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

7993-7993: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

8021-8032: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

8363-8366: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

8403-8405: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

8445-8450: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

8473-8484: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

8815-8818: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

8855-8857: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

8897-8902: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

8925-8936: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

9409-9410: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

9448-9455: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

9485-9493: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

9503-9535: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

13998-13999: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

14040-14042: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

14080-14084: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

14133-14146: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

15755-15756: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

15797-15800: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

15836-15841: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

15890-15901: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

20525-20527: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

20578-20580: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

20638-20642: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

20772-20785: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

21182-21185: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

21221-21224: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

21258-21262: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

21276-21289: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

28907-28910: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

28953-28964: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

29009-29013: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

29023-29027: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

29066-29079: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

29102-29115: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

31170-31172: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

31209-31212: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

31246-31250: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

31264-31277: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

31330-31332: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

31369-31372: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

31406-31410: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

31424-31437: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

32023-32025: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

32062-32065: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

32099-32103: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

32117-32129: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

33725-33728: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

33774-33785: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

33833-33837: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

33847-33851: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

33952-33965: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

33988-34002: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

38738-38741: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

38778-38781: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

38820-38825: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

38848-38859: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

39496-39499: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

39536-39539: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

39578-39583: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

39606-39617: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

42427-42429: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

42468-42479: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

42513-42518: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

42542-42574: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

42596-42610: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

42930-42935: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

42985-43004: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

43056-43063: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

43080-43091: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

43207-43211: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

43309-43313: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

43317-43340: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

43601-43609: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

43646-43677: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

43707-43760: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

---

43767-43907: Same approach as above—string-based uint64 reading/writing is consistent and avoids precision loss.

packages/dapi-grpc/clients/platform/v0/web/platform_pb.js (89)

4667-4670: Switch from numeric to string fields
These changes (height, timeMs) ensure 64-bit safety in JavaScript. Make sure surrounding code handles string values correctly.

---

4710-4710: Use of readUint64String
Switching to readUint64String() preserves full 64-bit values. Ensure consumers treat the field as a string or BigInt as needed.

---

4722-4722: Use of readUint64String
Again, this approach avoids precision loss for timeMs.

---

4763-4764: Conditional writing of string field
parseInt(f, 10) !== 0 is a standard check to skip writing a zero value.

---

4784-4785: Conditional writing of string field
Similar zero-check pattern ensures no redundant serialization of timeMs.

---

4809-4821: Getter/Setter to string
Changing the doc and return type to string is consistent with preserving 64-bit values.

---

4863-4871: Getter/Setter to string
These lines align the timeMs field with 64-bit string usage.

---

7911-7911: String-based nonce
Using string for identityNonce is correct to avoid numeric overflow.

---

7951-7951: readUint64String
Reading identityNonce as a string ensures full precision.

---

7993-7993: Uint64 string assignment
Writing the nonce as a string is consistent with the change.

---

8021-8021: Getter/Setter for identityNonce
Returning a string is correct given Proto jstype=JS_STRING.

---

8363-8363: String-based identityContractNonce
Same approach for contract nonce: no precision loss.

---

8403-8403: readUint64String
Ensures identityContractNonce is parsed as a full 64-bit string.

---

8445-8445: Uint64 string assignment
Consistently writing contract nonce value as a string.

---

8473-8473: Getter/Setter for identityContractNonce
Correctly returning and setting string values.

---

8815-8815: String-based balance
Preserving full 64-bit balance prevents overflow.

---

8855-8855: readUint64String
Reading the balance as a string.

---

8897-8897: Uint64 string assignment
Serializing balance as a string.

---

8925-8925: Getter/Setter for balance
Returning a string for balance is consistent with the PR’s objective.

---

9409-9410: Balance and Revision fields
Both switched to string to handle large numeric ranges.

---

9448-9452: readUint64String for balance & revision
Avoids losing precision on retrieval.

---

9485-9493: Conditional write of string fields
Using parseInt checks and writeUint64String to safely handle zero-value.

---

9503-9533: Getter/Setter for balance & revision
All references updated to string-based fields.

---

13998-13998: EvonodeProposedBlocks: count as string
Maintains 64-bit accuracy for block counts.

---

14040-14040: readUint64String for count
Ensures no integer overflow.

---

14080-14081: Conditional write
Skipping zero for count in serialization is standard PB pattern.

---

14133-14145: Getter/Setter for count
String-based approach is consistent with the rest of the PR.

---

15755-15755: GetIdentitiesBalancesResponse: string balance
Prevents overflow on large identity balances.

---

15797-15797: Uint64 string read
Reading the balance as a string.

---

15836-15838: Conditional write
Only writes a nonzero balance field.

---

15890-15901: Getter/Setter for balance
Consistent with the PB approach for 64-bit fields as strings.

---

20525-20525: startAtMs as string
Ensures time fields are not truncated.

---

20578-20578: readUint64String
Reading startAtMs as string to avoid numeric limits.

---

20638-20639: Conditional write of startAtMs
Checking parseInt for zero.

---

20772-20784: Getter/Setter for startAtMs
Properly storing time-based fields as strings.

---

21182-21182: date field as string
Keeps large timestamps intact.

---

21221-21221: readUint64String for date
Full 64-bit preservation for date.

---

21258-21259: Conditional write
Skipping zero date if parseInt returns 0.

---

21276-21288: Getter/Setter for date
Allows data contract history timestamps as strings.

---

28907-28909: Epoch info fields
Converting firstBlockHeight & startTime to strings.

---

28953-28961: readUint64String
Safely retrieves large epoch values for firstBlockHeight & startTime.

---

29009-29010: Conditional write
Omits default zero from serialization for firstBlockHeight.

---

29023-29024: Conditional write
Same skipping approach for startTime.

---

29066-29078: Getter/Setter for firstBlockHeight
Storing as string ensures no overflow.

---

29102-29114: Getter/Setter for startTime
Again, string-based approach for large numeric fields.

---

31170-31170: startTimeMs
Ensuring poll times remain accurate for large values.

---

31209-31209: readUint64String
Reading poll startTimeMs as string.

---

31246-31247: Conditional write
Skipping zero for poll startTimeMs.

---

31264-31276: Getter/Setter for poll startTimeMs
Maintaining 64-bit timestamps as strings.

---

31330-31330: endTimeMs as string
Preserves full precision for poll end times.

---

31369-31369: readUint64String
Reading endTimeMs without losing numeric precision.

---

31406-31407: Conditional write
Conditionally serializing endTimeMs if nonzero.

---

31424-31436: Getter/Setter for endTimeMs
Ensures accurate poll end time in string form.

---

32023-32023: timestamp as string
VotePollsByTimestamp uses strings for large time values.

---

32062-32062: readUint64String
Reading poll timestamp from binary as string.

---

32099-32100: Conditional write
Skipping zero poll timestamp.

---

32117-32129: Getter/Setter for poll timestamp
Full 64-bit coverage with string-based fields.

---

33725-33727: FinishedVoteInfo with block heights/times
Strings for blockHeight/day/timeMs to avoid overflow.

---

33774-33782: readUint64String
Reading finishedAtBlockHeight and finishedAtBlockTimeMs as string.

---

33833-33834: Conditional write for finishedAtBlockHeight
Standard parseInt check.

---

33847-33848: Conditional write for finishedAtBlockTimeMs
Same approach to skip zero.

---

33952-33964: Getter/Setter for finishedAtBlockHeight
String for block height plus updated doc.

---

33988-34000: Getter/Setter for finishedAtBlockTimeMs
String-based time ensures full precision.

---

38738-38738: Prefunded specialized balance
Storing as string to maintain large balances.

---

38778-38778: readUint64String
Extracting balance from binary as a string.

---

38820-38821: Conditional write
Only writes the balance if nonzero.

---

38848-38859: Getter/Setter for specialized balance
Maintaining string-based representation.

---

39496-39496: Total credits in platform
Switch to string for the credits field.

---

39536-39536: readUint64String
Reading credits without overflow.

---

39578-39579: Conditional write
Avoid serializing zero credits field.

---

39606-39617: Getter/Setter for credits
String-based approach consistent with large integer handling in JS.

---

42427-42429: Time fields (local, block, genesis)
Using strings to prevent potential overflow for large timestamps.

---

42468-42476: readUint64String
Retrieving local, block, genesis as strings.

---

42513-42528: Conditional writes for time fields
Skipping zero if parseInt results in 0.

---

42545-42574: Getter/Setter for time fields
All time fields use strings for 64-bit safety.

---

42599-42610: Getter/Setter for genesis
Retaining string-based usage for large timestamps.

---

42930-42934: Chain fields to strings
latestBlockHeight, earliestBlockHeight, maxPeerBlockHeight switched to string.

---

42985-42985: readUint64String for latestBlockHeight
No numeric truncation.

---

42997-43001: readUint64String for earliestBlockHeight & maxPeerBlockHeight
Same approach to maintain large numeric values.

---

43059-43060: Conditional write
Skipping zero for latestBlockHeight.

---

43080-43088: Conditional write
Same zero-skip for earliestBlockHeight, maxPeerBlockHeight.

---

43207-43219: Getter/Setter for chain’s block heights
Ensuring string usage for large block heights.

---

43309-43339: All chain getters/setters
EarliestBlockHeight & MaxPeerBlockHeight are stored as strings.

---

43601-43608: StateSync fields
Switching totalSyncedTime, remainingTime, etc. to strings.

---

43646-43674: readUint64String for multiple StateSync fields
ChunkProcessAvgTime, snapshotHeight, etc. handled as strings with parseInt checks.

---

43707-43715: Conditional write
Similarly skipping zero for totalSyncedTime, remainingTime.

---

43728-43757: Conditional writes for multiple fields
Ensures zero-value fields are not redundantly serialized.

---

43767-43797: Continuation of conditional writes
Chunk process time, snapshot blocks, all safe as strings.

---

43821-43904: Getter/Setter for StateSync
All relevant time/block fields use strings for 64-bit fidelity.

packages/js-dapi-client/lib/methods/platform/getStatus/NodeStatus.js (1)

1-24: LGTM! Well-structured class implementation.

The class follows best practices with:

• Clear JSDoc annotations
• Proper handling of optional parameters
• Consistent getter method naming

packages/js-dapi-client/lib/methods/platform/getDataContractHistory/DataContractHistoryEntry.js (1)

1-24: LGTM! Well-structured class implementation.

The class follows best practices with:

• Clear JSDoc annotations
• Proper use of bigint for timestamps
• Consistent getter method naming

packages/js-dapi-client/lib/methods/platform/getEpochsInfo/EpochInfo.js (2)

5-5: LGTM! Type conversion aligns with PR objectives.

The conversion of firstBlockHeight and startTime parameters from number to bigint helps prevent precision loss for large values.

Also applies to: 7-7

---

26-26: LGTM! Return type updates maintain type safety.

The return type updates in JSDoc for getFirstBlockHeight and getStartTime correctly reflect the bigint type conversion.

Also applies to: 40-40

packages/js-dapi-client/lib/methods/platform/getIdentityBalance/GetIdentityBalanceResponse.js (2)

6-6: LGTM! Type conversion ensures precision for balance values.

The conversion of balance from number to bigint in both parameter and return types helps prevent precision loss for large balance values.

Also applies to: 17-17

---

28-28: LGTM! Safe conversion to BigInt.

The explicit conversion using BigInt() in createFromProto ensures safe handling of large values from the protocol buffer response.

packages/js-dapi-client/lib/methods/platform/response/Metadata.js (3)

4-6: LGTM! Flexible parameter types with safe conversion.

The parameter type update to accept both bigint and string provides flexibility while maintaining type safety through explicit BigInt conversion.

---

10-12: LGTM! Safe conversion in constructor.

The constructor correctly converts input values to BigInt, ensuring consistent type handling throughout the class.

---

18-18: LGTM! Return type updates maintain type safety.

The return type updates in JSDoc for getHeight and getTimeMs correctly reflect the bigint type conversion.

Also applies to: 34-34

packages/js-dapi-client/lib/methods/platform/getIdentityNonce/GetIdentityNonceResponse.js (4)

4-4: LGTM! Proper use of BigInt for large integer filter.

The change from number to BigInt ensures accurate handling of large u64 values without precision loss.

---

8-8: LGTM! Correct type documentation.

The JSDoc update properly reflects the parameter type change to bigint.

---

19-19: LGTM! Return type properly documented.

The JSDoc update correctly reflects the return type change to bigint.

---

31-32: Verify proto value handling for large numbers.

The conversion to BigInt and bitwise filtering looks correct, but let's verify the proto implementation handles u64 values properly.

✅ Verification successful

Proto handling is correct.

The identity nonce is declared as a uint64 with [jstype = JS_STRING], ensuring that large numbers are transmitted as strings which are then safely converted to BigInt. The bitwise AND operation in the conversion is valid and properly handles the u64 value.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Check proto definition for identity nonce field
rg -A 5 "identity_nonce" packages/dapi-grpc/protos/platform/v0/platform.proto

# Check if jstype is properly set for u64 fields
rg "jstype.*JS_STRING.*uint64" packages/dapi-grpc/protos/platform/v0/platform.proto

Length of output: 287

packages/js-dash-sdk/src/SDK/Client/Platform/methods/identities/get.ts (1)

34-40: LGTM! Improved Metadata instantiation.

The change from object literal to direct constructor arguments improves type safety and makes the code more maintainable.

packages/js-dapi-client/lib/methods/platform/response/AbstractResponse.js (1)

53-58: LGTM! Consistent Metadata instantiation pattern.

The change follows the same pattern as seen in other files, using structured object initialization for Metadata.

packages/js-dapi-client/lib/methods/platform/getDataContractHistory/GetDataContractHistoryResponse.js (1)

7-7: LGTM! Improved type safety with DataContractHistoryEntry.

The change from object to typed array improves type safety and code clarity.

Also applies to: 18-18

packages/wasm-dpp/src/errors/consensus/fee/balance_is_not_enough_error.rs (2)

32-34: LGTM! Improved type safety by using u64.

The change from f64 to u64 for balance prevents precision loss and aligns with the PR objectives.

---

37-39: Verify the fee type cast.

The as u64 cast might need verification to ensure no precision loss occurs during conversion.

✅ Verification successful

I'm going to run some additional commands to inspect the implementation details in the file and to locate the declaration of the fee() method. This will help us verify the underlying fee type and whether the conversion performed by as u64 is safe (i.e. that no precision loss will occur).

---

I'm going to run additional shell scripts to search for the underlying definition of the Credits type and for the full implementation of BalanceIsNotEnoughError, which should help us verify whether the as u64 cast is safe with respect to precision loss.

---

Verification of the fee type cast is correct.

• The underlying fee() method returns a value of type Credits, which is defined as u64 in packages/rs-dpp/src/balances/credits.rs.
• Since both the original type and the target type are u64, converting with as u64 will not result in any precision loss.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for fee() method implementation to verify its return type
ast-grep --pattern 'impl BalanceIsNotEnoughError {
  $$$
  fn fee(&self) -> $type {
    $$$
  }
  $$$
}'

Length of output: 106

---

Script:

#!/bin/bash
# 1. Print the beginning of the file to inspect the struct and its inner field.
sed -n '1,150p' packages/wasm-dpp/src/errors/consensus/fee/balance_is_not_enough_error.rs

# 2. Search across the repository for any definition of `fn fee(&self)` to find its return type.
rg "fn fee(&self)" -t rust

Length of output: 1818

---

Script:

#!/bin/bash
echo "Searching for the Credits type definition:"
rg "pub type Credits" -t rust -C 3

echo "Searching for BalanceIsNotEnoughError implementation and fee() method:"
rg "impl BalanceIsNotEnoughError" -t rust -C 20

Length of output: 9766

packages/js-dapi-client/lib/methods/platform/getStatus/getStatusFactory.js (1)

9-9: LGTM! Well-documented changes with proper error handling.

The updated return types and JSDoc comments accurately reflect the new functionality.

Also applies to: 13-13, 17-20

packages/js-dash-sdk/src/SDK/Client/Platform/methods/contracts/history.ts (1)

15-17: LGTM! Proper type safety for large integers.

The change from number to bigint for startAtMs prevents precision loss and aligns with the PR objectives.

Also applies to: 23-23

packages/js-dash-sdk/src/SDK/Client/Platform/methods/contracts/update.ts (1)

34-35: Verify nonce type consistency across the codebase.

The removal of explicit BigInt() conversion suggests that identityContractNonce is already a BigInt. Let's verify this assumption.

✅ Verification successful

Nonce Type Consistency Verified

• The NonceManager’s bumpIdentityContractNonce method performs addition using the BigInt literal (+ 1n), which implies that the nonce is expected to be a BigInt.
• The returned nonce from getIdentityContractNonce (via the dapi-client’s GetIdentityContractNonceResponse) is converted to BigInt before being utilized.
• Although some test mocks resolve the nonce as a number (e.g. 1), the production code consistently operates on BigInt values, making the removal of the explicit BigInt() conversion in update.ts correct.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for bumpIdentityContractNonce return type and usage
ast-grep --pattern 'bumpIdentityContractNonce($$$)'

# Search for other nonce-related methods
rg -A 5 'identityContractNonce'

Length of output: 42560

packages/js-dapi-client/lib/methods/platform/getStatus/VersionStatus.js (1)

1-77: LGTM! Well-structured class with proper documentation.

The class is well-designed with:

• Clear JSDoc documentation
• Proper getter methods
• Appropriate use of number type for protocol versions

packages/wasm-dpp/src/metadata.rs (1)

37-45: LGTM! Constructor changes improve type safety.

The explicit type parameters instead of JsValue improve type safety and align with the PR objective to fix uint64 handling.

packages/js-dash-sdk/src/SDK/Client/Platform/NonceManager/NonceManager.ts (2)

4-7: LGTM! Type changes align with uint64 handling requirements.

The conversion from number to bigint for the value property in NonceState type and the nonce parameter in setIdentityNonce method is appropriate for handling uint64 values without precision loss.

Also applies to: 26-38

---

40-72: LGTM! Proper handling of bigint nonce values.

The method correctly handles bigint values throughout its execution, maintaining precision for uint64 nonce values.

packages/js-dapi-client/test/unit/methods/platform/getIdentityNonce/GetIdentityNonce.spec.js (1)

25-25: LGTM! Tests properly validate bigint handling.

The test cases have been correctly updated to use BigInt for nonce values and metadata assertions, ensuring proper validation of uint64 handling.

Also applies to: 104-114

packages/js-dapi-client/test/unit/methods/platform/getIdentityBalance/GetIdentityBalanceResponse.spec.js (1)

26-26: LGTM! Tests properly validate bigint balance handling.

The test cases have been correctly updated to use BigInt for balance values and metadata assertions, ensuring proper validation of uint64 handling.

Also applies to: 104-113

packages/js-dapi-client/test/unit/methods/platform/getIdentityKeys/GetIdentityKeys.spec.js (1)

109-116: LGTM! Tests properly validate bigint metadata fields.

The test cases have been correctly updated to use BigInt for metadata assertions, ensuring proper validation of uint64 handling in height and timeMs fields.

packages/js-dapi-client/test/unit/methods/platform/getIdentityNonce/getIdentityNonceFactory.spec.js (2)

28-28: LGTM! Proper handling of nonce as BigInt.

The conversion of nonce to BigInt aligns with the PR objective to handle u64 values correctly.

---

85-92: LGTM! Enhanced metadata assertions with proper type handling.

The granular assertions for metadata properties with explicit BigInt conversions improve type safety and test precision.

Also applies to: 121-128

packages/js-dapi-client/test/unit/methods/platform/getDocuments/GetDocumentsResponse.spec.js (2)

39-40: LGTM! Complete metadata setup.

Added missing metadata fields (timeMs and protocolVersion) for comprehensive testing.

---

87-94: LGTM! Enhanced metadata assertions with proper type handling.

The granular assertions for metadata properties with explicit BigInt conversions improve type safety and test precision.

Also applies to: 113-120

packages/js-dapi-client/test/unit/methods/platform/getIdentity/getIdentityFactory.spec.js (1)

87-94: LGTM! Enhanced metadata assertions with proper type handling.

The granular assertions for metadata properties with explicit BigInt conversions improve type safety and test precision.

Also applies to: 123-130

packages/js-dapi-client/test/unit/methods/platform/getIdentityBalance/getIdentityBalanceFactory.spec.js (3)

30-30: LGTM! Proper handling of balance as BigInt.

The conversion of balance to BigInt aligns with the PR objective to handle u64 values correctly.

---

88-95: LGTM! Enhanced metadata assertions with proper type handling.

The granular assertions for metadata properties with explicit BigInt conversions improve type safety and test precision.

Also applies to: 124-131

---

122-122: LGTM! Proper handling of default balance as BigInt.

The assertion correctly expects a BigInt(0) for undefined balance.

packages/js-dapi-client/lib/methods/platform/getStatus/GetStatusResponse.js (1)

1-67: LGTM! Well-structured class with proper encapsulation.

The class follows good OOP principles with clear separation of concerns, proper encapsulation through getter methods, and thorough JSDoc documentation.

packages/wasm-dpp/src/document/state_transition/document_batch_transition/document_transition/mod.rs (1)

20-20: LGTM! Improved type safety with Option.

The change from JsValue to Option<Revision> leverages Rust's type system better and provides clearer semantics about the possibility of missing revisions.

Also applies to: 63-64

packages/js-dapi-client/test/unit/methods/platform/getIdentityContractNonce/GetIdentityContractNonce.spec.js (1)

25-25: LGTM! Consistent use of BigInt for uint64 values.

The changes properly handle uint64 values by using BigInt, aligning with the PR's objective to prevent precision loss. The assertions are updated consistently to use BigInt comparisons.

Also applies to: 105-114

packages/js-dapi-client/test/unit/methods/platform/getDataContract/getDataContractFactory.spec.js (1)

88-95: LGTM! Consistent BigInt assertions for metadata fields.

The test assertions are properly updated to use BigInt for uint64 values in metadata fields, maintaining consistency with the PR's objective to handle large numbers correctly.

Also applies to: 129-136

packages/js-dapi-client/test/unit/methods/platform/getIdentity/GetIdentityResponse.spec.js (1)

82-89: LGTM! Proper handling of uint64 values.

The test now correctly validates uint64 fields (height and timeMs) using BigInt, preventing potential precision loss.

packages/js-dapi-client/test/unit/methods/platform/getIdentityContractNonce/getIdentityContractNonceFactory.spec.js (1)

29-29: LGTM! Proper initialization of nonce as BigInt.

The nonce value is now correctly initialized as BigInt(1), preventing potential precision loss.

packages/js-dapi-client/test/unit/methods/platform/getIdentityByPublicKeyHash/getIdentityByPublicKeyHashFactory.spec.js (1)

92-99: LGTM! Proper validation of uint64 metadata fields.

The test now correctly validates uint64 fields (height and timeMs) using BigInt, preventing potential precision loss.

packages/js-dapi-client/test/unit/methods/platform/getProtocolVersionUpgradeState/getProtocolVersionUpgradeStateFactory.spec.js (1)

91-98: LGTM! Proper handling of uint64 values using BigInt.

The changes correctly update the metadata assertions to use BigInt for height and timeMs fields, ensuring proper handling of uint64 values without precision loss.

Also applies to: 127-134

packages/js-dapi-client/test/unit/methods/platform/getIdentityKeys/getIdentityKeysFactory.spec.js (1)

99-106: LGTM! Consistent BigInt handling for uint64 values.

The changes maintain consistency with other files by properly handling uint64 values using BigInt for height and timeMs fields in metadata assertions.

Also applies to: 138-145

packages/js-dash-sdk/src/SDK/Client/Platform/Fetcher/Fetcher.ts (1)

131-134: LGTM! Clear parameter documentation.

The JSDoc comments clearly document the parameter types, making it easy for developers to understand the expected types.

packages/js-dapi-client/test/unit/methods/platform/waitForStateTransitionResult/waitForStateTransitionResultFactory.spec.js (1)

58-65: LGTM! Comprehensive BigInt handling across test cases.

The changes consistently update all metadata assertions across different test cases to properly handle uint64 values using BigInt, maintaining test coverage while improving type safety.

Also applies to: 100-107, 149-156

packages/js-dapi-client/test/unit/methods/platform/getEpochsInfo/getEpochsInfoFactory.spec.js (2)

30-30: LGTM: Proper BigInt usage for large integers

The initialization of epochInfoFixture correctly uses BigInt for values that could exceed JavaScript's Number.MAX_SAFE_INTEGER.

---

95-102: LGTM: Consistent BigInt assertions for metadata fields

The test assertions properly validate that height and timeMs are handled as BigInt values while maintaining regular number comparisons for other fields.

Also applies to: 134-141

packages/js-dapi-client/test/unit/methods/platform/getProtocolVersionUpgradeState/GetProtocolVersionUpgradeStateResponse.spec.js (1)

114-121: LGTM: Proper metadata field type assertions

The test correctly validates that height and timeMs are handled as BigInt values while maintaining regular number comparisons for coreChainLockedHeight and protocolVersion.

packages/js-dapi-client/test/unit/methods/platform/getEpochsInfo/GetEpochsInfoResponse.spec.js (2)

26-26: LGTM: Proper BigInt initialization

The initialization of epochInfoFixture correctly uses BigInt for values that could exceed JavaScript's Number.MAX_SAFE_INTEGER.

---

83-90: LGTM: Comprehensive BigInt assertions

The test cases thoroughly validate BigInt handling for metadata fields across different scenarios, ensuring consistent type handling.

Also applies to: 98-105, 125-132

packages/js-dapi-client/test/unit/methods/platform/getProtocolVersionUpgradeVoteStatus/GetProtocolVersionUpgradeVoteStatusResponse.spec.js (1)

117-124: LGTM: Proper metadata field type assertions

The test correctly validates that height and timeMs are handled as BigInt values while maintaining regular number comparisons for coreChainLockedHeight and protocolVersion.

packages/js-dapi-client/test/unit/methods/platform/getProtocolVersionUpgradeVoteStatus/getProtocolVersionUpgradeVoteStatusFactory.spec.js (1)

101-108: LGTM! Test assertions updated to handle BigInt values.

The test assertions have been correctly updated to handle u64 values using BigInt for height and timeMs fields, while maintaining regular number comparisons for other fields. This aligns with the PR objectives.

packages/js-dapi-client/test/unit/methods/platform/getDataContract/GetDataContractResponse.spec.js (1)

66-67: LGTM! Test coverage expanded for metadata fields.

The test has been properly updated to:

1. Set new metadata fields (timeMs and protocolVersion)
2. Assert BigInt values for numeric fields

Also applies to: 79-86

packages/js-dapi-client/test/unit/methods/platform/getDocuments/getDocumentsFactory.spec.js (1)

113-120: LGTM! Consistent BigInt handling across test cases.

The test assertions have been systematically updated across all test cases to handle u64 values using BigInt, maintaining consistency throughout the test suite.

Also applies to: 154-161, 195-202

packages/js-dapi-client/test/unit/methods/platform/getDataContractHistory/getDataContractHistoryFactory.spec.js (3)

45-52: LGTM! Clear and structured history fixture.

The data contract history fixture has been well-structured with explicit date and value properties, improving test readability.

---

129-136: LGTM! Consistent BigInt handling for metadata.

The metadata assertions have been properly updated to handle u64 values using BigInt, maintaining consistency with other tests.

Also applies to: 173-180

---

165-165: Verify the change in empty result representation.

The test now expects null instead of an empty array when no history is available. Please verify if this change is intentional and aligns with the API contract.

✅ Verification successful

Review Verification: Empty Result Representation

The tests now consistently expect that when no data contract history is available the response represents it as null rather than an empty array. In various test scenarios (e.g. in both GetDataContractHistoryResponse and getDataContractHistoryFactory tests), the expectation is explicitly set to null. This indicates that the change was intentional and is aligned with the API contract.

No issues were found with this change.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for other instances of getDataContractHistory result handling
rg -A 5 'getDataContractHistory\(\)' --type js

Length of output: 10483

packages/js-dapi-client/test/unit/methods/platform/getIdentitiesContractKeys/getIdentitiesContractKeysFactory.spec.js (1)

147-155: LGTM! Metadata assertions correctly updated to use BigInt.

The changes properly handle uint64 values by using BigInt for height and timeMs fields in metadata assertions, which aligns with the PR objectives to prevent precision loss.

Also applies to: 182-189

packages/js-dapi-client/test/unit/methods/platform/getIdentitiesContractKeys/GetIdentitiesContractKeysResponse.spec.js (1)

114-121: LGTM! Metadata assertions correctly updated to use BigInt.

The changes properly handle uint64 values by using BigInt for height and timeMs fields in metadata assertions, which aligns with the PR objectives to prevent precision loss.

Also applies to: 164-171

packages/js-dapi-client/test/unit/methods/platform/getDataContractHistory/GetDataContractHistoryResponse.spec.js (2)

28-35: LGTM! Data contract history structure updated to use array format.

The data contract history fixture has been correctly updated to use an array of objects with date and value properties, which provides a clearer and more structured representation.

---

151-158: LGTM! Metadata assertions correctly updated to use BigInt.

The changes properly handle uint64 values by using BigInt for height and timeMs fields in metadata assertions, which aligns with the PR objectives to prevent precision loss.

packages/wasm-dpp/src/identity/identity.rs (2)

108-115: LGTM! Balance methods correctly updated to use u64.

The balance-related methods have been properly updated to use u64 instead of f64, which prevents precision loss when handling large integers.

---

133-140: LGTM! Revision methods correctly updated to use u64.

The revision-related methods have been properly updated to use u64 instead of f64, which prevents precision loss when handling large integers.

packages/wasm-dpp/src/identity/state_transition/identity_credit_transfer_transition/transition.rs (1)

93-94: LGTM! The changes correctly handle uint64 values.

The modifications properly address the uint64 handling issue by:

1. Using u64 instead of f64 for amount values
2. Converting amounts to BigInt when serializing to JavaScript

Also applies to: 98-99, 164-164, 239-239

packages/js-dapi-client/test/unit/methods/platform/getStatus/getStatusFactory.spec.js (1)

1-279: LGTM! Comprehensive test coverage for getStatus functionality.

The test suite is well-structured with:

• Complete coverage of success paths
• Proper BigInt handling verification
• Thorough assertions for all fields
• Edge case handling for optional fields

packages/wasm-dpp/src/data_contract/data_contract.rs (1)

316-317: LGTM! Improved parameter naming.

The parameter rename from 'e' to 'nonce' enhances code readability while maintaining the same functionality.

packages/wasm-dpp/src/document/state_transition/document_batch_transition/mod.rs (1)

131-132: LGTM! The change aligns with the PR objectives.

The parameter type change from u32 to u64 for set_identity_contract_nonce is correct and necessary to prevent precision loss when handling large nonce values.

Run the following script to verify the impact of this change:

✅ Verification successful

Nonce Type Update Verified: No Remaining u32 Occurrences Found

The additional searches using ripgrep showed no instances of nonce: u32 usage in either type declarations or function parameters, indicating that the change from u32 to u64 has been fully implemented.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for any remaining u32 nonce types in the codebase that might need similar updates.

# Search for nonce-related type declarations
ast-grep --pattern $'type $_nonce$_: u32'

# Search for nonce-related function parameters
ast-grep --pattern $'fn $_($_ nonce: u32)'

Length of output: 86

---

Script:

#!/bin/bash
# Description: Perform additional searches for 'nonce' references that may be using u32.
# This script uses ripgrep (rg) to scan the entire repository for occurrences where nonce parameters or types are declared as u32.

echo "Searching for explicit 'nonce: u32' occurrences..."
rg -n "nonce: u32"

echo -e "\nSearching for functions with 'nonce: u32' parameters..."
rg -n "fn .*nonce: u32" 

echo -e "\nSearching for any lines with both 'nonce' and 'u32' for additional context..."
rg -n "nonce.*u32|u32.*nonce"

Length of output: 511

packages/js-dapi-client/test/unit/methods/platform/getStatus/GetStatusResponse.spec.js (2)

99-104: LGTM! Proper BigInt conversions for large numbers.

The test correctly converts numeric values that could exceed JavaScript's Number.MAX_SAFE_INTEGER to BigInt, preventing precision loss:

• Chain heights and peer heights
• State sync times and block counts
• Timestamps

Also applies to: 114-121, 125-128

---

194-268: LGTM! Comprehensive test coverage.

The test suite thoroughly verifies:

1. All status components (version, node, chain, network, state sync, time)
2. Proper type conversions for all fields
3. Instance creation from proto
4. Getter methods for all properties

Also applies to: 270-346

packages/dapi-grpc/clients/platform/v0/web/platform_pb.d.ts (9)

58-59: LGTM: ResponseMetadata type changes align with uint64 handling

The changes to convert height and timeMs fields from number to string type in ResponseMetadata are consistent with the PR objective to fix uint64 handling and prevent precision loss.

Also applies to: 67-68, 88-91

---

537-538: LGTM: GetIdentityNonceResponse type changes

Converting identityNonce field from number to string type is appropriate for handling uint64 values without precision loss.

Also applies to: 563-563

---

606-607: LGTM: GetIdentityContractNonceResponse type changes

Converting identityContractNonce field from number to string type is consistent with the uint64 handling improvements.

Also applies to: 632-632

---

675-676: LGTM: Balance and revision type changes

Converting balance and revision fields from number to string type in balance-related responses is appropriate for handling uint64 values.

Also applies to: 701-701, 776-780, 794-795

---

2405-2406: LGTM: Data contract history timestamp type changes

Converting timestamp fields (startAtMs and date) from number to string type is consistent with handling large integer values.

Also applies to: 2426-2426, 2494-2495, 2514-2514

---

3970-3971: LGTM: Vote poll timestamp type changes

Converting timestamp fields (startTimeMs, endTimeMs, and timestamp) from number to string type is appropriate for handling uint64 values.

Also applies to: 3988-3989, 3994-3995, 4012-4013, 4081-4082, 4103-4104

---

5607-5618: LGTM: Status response time and block height type changes

Converting time and block height related fields from number to string type in status responses is consistent with handling large integer values.

Also applies to: 5764-5787

---

5035-5036: LGTM: Balance and credits type changes

Converting balance and credits fields from number to string type in specialized balance and platform credits responses is appropriate for handling uint64 values.

Also applies to: 5061-5061, 5152-5153, 5178-5178

---

58-5809: Verify the completeness of uint64 type changes

Let's verify that all uint64 fields have been converted to string type consistently.

✅ Verification successful

uint64 Type Conversion Verification

The search results indicate that for the Platform client the uint64 fields that need conversion (for example, the height and timeMs fields) are now declared as strings as expected. The other numeric fields that remain (such as epoch and protocolVersion) are left as numbers—this is intentional because only fields that risk exceeding JavaScript’s safe number range (uint64 values) require conversion to string. In short, the conversion has been applied consistently based on each field’s requirements.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Search for any remaining number type fields that might need conversion
rg -A 1 'get\w+\(\):' | rg 'number' 

Length of output: 13148

🧰 Tools

🪛 Biome (1.9.4)

[error] 161-162: Don't use '{}' as a type.

Prefer explicitly define the object shape. '{}' means "any non-nullable value".

(lint/complexity/noBannedTypes)

---

[error] 866-867: Don't use '{}' as a type.

Prefer explicitly define the object shape. '{}' means "any non-nullable value".

(lint/complexity/noBannedTypes)

---

[error] 5387-5388: Don't use '{}' as a type.

Prefer explicitly define the object shape. '{}' means "any non-nullable value".

(lint/complexity/noBannedTypes)

packages/js-dash-sdk/tsconfig.json (1)

2-4: Update TypeScript Target Version
Changing "target": "es2020" (from the older ES5 setting) enables modern JavaScript features—including native BigInt support—which is essential for safely handling large integer values in the codebase.

packages/dapi-grpc/protos/platform/v0/platform.proto (15)

71-78: Ensure Consistent BigInt Handling in ResponseMetadata
In the ResponseMetadata message, fields like height and time_ms are now annotated with [jstype = JS_STRING] to prevent precision loss for large blockchain values. Please verify that any downstream code expecting numeric types is updated to handle these as string representations.

---

163-174: BigInt Conversion in GetIdentityNonceResponse
The identity_nonce field now uses [jstype = JS_STRING] to safely represent uint64 values in JavaScript. Confirm that any consumers or serialization logic correctly handle this string conversion.

---

176-187: Safe Representation for Identity Contract Nonce
The identity_contract_nonce field has been updated with [jstype = JS_STRING] to avoid precision issues. Ensure that the client code deserializes this value appropriately.

---

189-200: BigInt Handling for Identity Balance
The balance field in GetIdentityBalanceResponse is now expressed with [jstype = JS_STRING], which prevents precision loss when working with large balance figures. Verify that downstream consumers correctly process the new string format.

---

205-208: Ensure Precise Handling of Balance and Revision
Inside GetIdentityBalanceAndRevisionResponse, both balance and revision fields now use [jstype = JS_STRING]. This update is crucial for accurately representing large numbers, so please confirm consistency across all client-side operations.

---

377-380: Convert Identity Balance to String
In the GetIdentitiesBalancesResponse message, the optional balance field is now marked with [jstype = JS_STRING] to preserve numeric precision. Ensure that any code consuming these balance values handles them as strings or converts them safely.

---

510-513: String Representation for Start Timestamp
The start_at_ms field in GetDataContractHistoryRequest now specifies [jstype = JS_STRING]. This change is critical for preventing precision loss in large millisecond timestamps. Please double-check that any filtering or comparison operations account for the string format.

---

521-523: Maintain Precision in Contract History Dates
The date field within the DataContractHistoryEntry message now uses [jstype = JS_STRING], ensuring that large timestamp values are correctly preserved. Confirm that any date processing routines are updated accordingly.

---

1025-1028: Correct Data Type for Specialized Balance
In GetPrefundedSpecializedBalanceResponse, the balance field has been updated with [jstype = JS_STRING]. This modification prevents precision issues when dealing with large numbers. Please ensure that any consumer of this field correctly handles the string type.

---

1047-1050: BigInt Support for Total Credits
The credits field in GetTotalCreditsInPlatformResponse now uses [jstype = JS_STRING] to accurately capture large numeric totals. Verify that subsequent processing logic treats these values appropriately.

---

731-742: Epoch Information: Handling Large Numbers
Within the EpochInfo message of GetEpochsInfoResponse, fields such as first_block_height and start_time are now annotated with [jstype = JS_STRING]. This change is important for avoiding precision loss in blockchain metrics.

---

800-807: Timestamp Precision in Vote Polls Request
Both start_time_ms (in StartAtTimeInfo) and end_time_ms (in EndAtTimeInfo) in GetVotePollsByEndDateRequest now use [jstype = JS_STRING]. This ensures that time-based filtering remains accurate even with very large numbers.

---

823-825: Vote Polls Timestamp as String
The timestamp field in SerializedVotePollsByTimestamp within GetVotePollsByEndDateResponse is now marked with [jstype = JS_STRING] to support high-precision time values. Please ensure vote processing logic adheres to this new representation.

---

876-888: Accurate Vote State Timestamps and Block Height
Within the FinishedVoteInfo of GetContestedResourceVoteStateResponse, both finished_at_block_height and finished_at_block_time_ms now use [jstype = JS_STRING]. This is essential to maintain precision in vote result evaluations.

---

1130-1176: BigInt Handling in GetStatusResponse
Multiple numeric fields in the GetStatusResponse message—including time values in the Time message, block heights in the Chain message, and various metrics in StateSync—are now annotated with [jstype = JS_STRING]. This comprehensive update ensures that large values are safely represented as strings throughout status reporting. Please review any client-side conversions to maintain consistency.

Reviewing files that changed from the base of the PR and between a69bbeb and 677b83b.

• packages/platform-test-suite/test/functional/platform/Identity.spec.js (1 hunks)

• GitHub Check: Rust packages (wasm-dpp) / Linting
• GitHub Check: Rust packages (dash-sdk) / Tests
• GitHub Check: Build JS packages / Build JS

packages/platform-test-suite/test/functional/platform/Identity.spec.js (1)

324-324: Add test cases for large uint64 values.

Given that this PR aims to fix precision loss issues with uint64 values, consider adding test cases that verify behavior with values exceeding Number.MAX_SAFE_INTEGER (2^53 - 1).

Example test cases to consider:

it('should handle large uint64 values correctly', async () => {
  const largeAmount = BigInt('18446744073709551615'); // max uint64
  const mediumAmount = BigInt('9223372036854775807'); // max int64
  
  // Test credit transfer with large amounts
  await client.platform.identities.creditTransfer(
    identity,
    recipient.getId(),
    largeAmount,
  );
  
  const recipientAfterTransfer = await client.platform.identities.get(
    recipient.getId(),
  );
  
  expect(recipientAfterTransfer.getBalance()).to.be.a('bigint')
    .and.to.equal(largeAmount);
});

Reviewing files that changed from the base of the PR and between 4999e1a and 512eebf.

• packages/platform-test-suite/test/e2e/withdrawals.spec.js (3 hunks)
• packages/platform-test-suite/test/functional/platform/Document.spec.js (1 hunks)
• packages/platform-test-suite/test/functional/platform/Identity.spec.js (8 hunks)

• GitHub Check: Rust packages (wasm-dpp) / Tests
• GitHub Check: Rust packages (dash-sdk) / Unused dependencies
• GitHub Check: Rust packages (dash-sdk) / Formatting
• GitHub Check: Rust packages (dapi-grpc) / Unused dependencies
• GitHub Check: Rust packages (dapi-grpc) / Tests
• GitHub Check: Build JS packages / Build JS

packages/platform-test-suite/test/functional/platform/Document.spec.js (1)

303-303: LGTM! The BigInt conversion aligns with PR objectives.

The change from numeric to BigInt increment is correct and consistent with the PR's goal of properly handling uint64 values.

Note that this change is within a skipped test case. Please verify if this test can be unskipped now that the BigInt conversion is in place.

packages/platform-test-suite/test/e2e/withdrawals.spec.js (3)

113-113: LGTM! Correct assertion style for BigInt comparison.

The change to use native JavaScript comparison operators instead of Chai's built-in assertions is the right approach for comparing BigInt values.

---

175-175: LGTM! Correct BigInt multiplication.

The explicit conversion of the multiplier to BigInt using BigInt(2) is necessary as BigInt values can only be operated with other BigInt values.

---

190-190: LGTM! Correct BigInt division.

The explicit conversion of the divisor to BigInt using BigInt(2) is necessary as BigInt values can only be operated with other BigInt values.

packages/platform-test-suite/test/functional/platform/Identity.spec.js (5)

232-232: LGTM! Balance comparison updates align with BigInt migration.

The changes correctly update balance comparisons to use direct boolean expressions, which is more explicit and compatible with BigInt values.

Also applies to: 320-320, 433-435

---

422-422: LGTM! Proper BigInt calculation for credit amounts.

The calculation correctly uses BigInt for both operands to prevent precision loss when dealing with large numbers.

---

551-552: LGTM! Credit transfer assertions properly handle BigInt values.

The balance comparisons and arithmetic operations correctly use BigInt, ensuring precise credit transfer validation.

Also applies to: 555-556

---

570-570: LGTM! Proper BigInt usage in insufficient balance test.

The test correctly uses BigInt addition to verify the behavior when attempting to transfer more credits than available.

---

622-622: LGTM! Revision comparisons updated to use BigInt.

The identity revision comparisons are correctly updated to use BigInt arithmetic, maintaining consistency with the uint64 migration.

Also applies to: 654-654

Reviewing files that changed from the base of the PR and between 512eebf and 099bc62.

• packages/js-dapi-client/lib/methods/platform/getDataContractHistory/GetDataContractHistoryResponse.js (3 hunks)
• packages/js-dash-sdk/src/SDK/Client/Platform/methods/contracts/history.ts (2 hunks)
• packages/platform-test-suite/test/e2e/withdrawals.spec.js (4 hunks)
• packages/platform-test-suite/test/functional/platform/Epoch.spec.js (1 hunks)
• packages/wasm-dpp/src/document/state_transition/document_batch_transition/document_transition/mod.rs (3 hunks)
• packages/wasm-dpp/src/metadata.rs (2 hunks)

• packages/wasm-dpp/src/document/state_transition/document_batch_transition/document_transition/mod.rs
• packages/js-dash-sdk/src/SDK/Client/Platform/methods/contracts/history.ts
• packages/platform-test-suite/test/e2e/withdrawals.spec.js
• packages/js-dapi-client/lib/methods/platform/getDataContractHistory/GetDataContractHistoryResponse.js

• GitHub Check: Rust packages (wasm-dpp) / Linting
• GitHub Check: Build Docker images (Dashmate helper, dashmate-helper, dashmate-helper) / Build Dashmate helper image
• GitHub Check: Build Docker images (DAPI, dapi, dapi) / Build DAPI image
• GitHub Check: Build JS packages / Build JS

packages/platform-test-suite/test/functional/platform/Epoch.spec.js (1)

27-27: LGTM! Verify other uint64 fields in the response.

The change to use BigInt(1) aligns with the PR's objective to handle uint64 values correctly. This prevents potential precision loss issues.

Please verify that all other uint64 fields in the getEpochsInfo response are also being handled as BigInt. Run this script to check the response structure:

✅ Verification successful

🏁 Script executed:

#!/bin/bash
# Description: Check for other uint64 fields in the getEpochsInfo response that might need BigInt assertions

# Search for field definitions in proto files
rg -A 5 "uint64.*first_block_height|uint64.*epoch" packages/dapi-grpc/protos/

Length of output: 957

---

Double-check BigInt Conversions in getEpochsInfo Response

The shell script confirms that, besides the already-updated first_block_height, the proto defines another uint64 field: start_time (also annotated with jstype = JS_STRING). Please ensure that any tests or code using start_time similarly convert or assert its value as a BigInt where precision is critical.

Reviewing files that changed from the base of the PR and between 099bc62 and 89ca6e2.

• packages/js-dapi-client/test/unit/methods/platform/getDataContractHistory/GetDataContractHistoryResponse.spec.js (8 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getDataContractHistory/getDataContractHistoryFactory.spec.js (8 hunks)

• packages/js-dapi-client/test/unit/methods/platform/getDataContractHistory/getDataContractHistoryFactory.spec.js

• GitHub Check: Rust packages (wasm-dpp) / Linting
• GitHub Check: Build JS packages / Build JS

packages/js-dapi-client/test/unit/methods/platform/getDataContractHistory/GetDataContractHistoryResponse.spec.js (2)

28-35: LGTM! Proper BigInt usage in fixture setup.

The fixture correctly uses BigInt for date values, aligning with the PR's objective to handle uint64 values properly.

---

77-78: LGTM! Proper handling of proto conversion and metadata.

The implementation correctly:

• Sets proto date values as strings
• Converts metadata numeric fields to BigInt
• Includes proper assertions for all metadata fields

Also applies to: 82-83, 151-158

Reviewing files that changed from the base of the PR and between 89ca6e2 and 6cf9e43.

• packages/js-dapi-client/lib/BlockHeadersProvider/BlockHeadersProvider.js (7 hunks)
• packages/js-dapi-client/lib/methods/platform/getStatus/ChainStatus.js (1 hunks)
• packages/js-dapi-client/lib/methods/platform/getStatus/TimeStatus.js (1 hunks)
• packages/js-dapi-client/lib/test/fixtures/getMetadataFixture.js (1 hunks)
• packages/js-dash-sdk/src/SDK/Client/Client.ts (1 hunks)
• packages/js-dash-sdk/src/SDK/Client/Platform/Fetcher/Fetcher.ts (1 hunks)
• packages/js-dash-sdk/src/SDK/Client/Platform/methods/contracts/history.spec.ts (2 hunks)
• packages/rs-dpp/src/state_transition/state_transitions/document/documents_batch_transition/document_transition/mod.rs (1 hunks)
• packages/wallet-lib/src/plugins/Workers/TransactionsSyncWorker/TransactionsReader.spec.js (3 hunks)
• packages/wallet-lib/src/plugins/Workers/TransactionsSyncWorker/TransactionsSyncWorker.spec.js (1 hunks)
• packages/wasm-dpp/src/document/state_transition/document_batch_transition/document_transition/document_create_transition.rs (2 hunks)
• packages/wasm-dpp/src/document/state_transition/document_batch_transition/document_transition/document_delete_transition.rs (1 hunks)
• packages/wasm-dpp/src/document/state_transition/document_batch_transition/document_transition/document_replace_transition.rs (1 hunks)
• packages/wasm-dpp/src/identity/state_transition/identity_credit_transfer_transition/transition.rs (4 hunks)
• packages/wasm-dpp/src/identity/state_transition/identity_update_transition/identity_update_transition.rs (2 hunks)
• packages/wasm-dpp/test/integration/identity/IdentityFacade.spec.js (3 hunks)
• packages/wasm-dpp/test/integration/identity/stateTransition/IdentityUpdateTransition/validation/state/validateIdentityUpdateTransitionStateFactory.spec.js (4 hunks)
• packages/wasm-dpp/test/integration/identity/stateTransition/assetLockProof/chain/validateChainAssetLockProofStructureFactory.spec.js (3 hunks)
• packages/wasm-dpp/test/integration/identity/stateTransition/assetLockProof/fetchAssetLockTransactionOutputFactory.spec.js (1 hunks)

• packages/wasm-dpp/test/integration/identity/stateTransition/assetLockProof/fetchAssetLockTransactionOutputFactory.spec.js
• packages/wasm-dpp/src/document/state_transition/document_batch_transition/document_transition/document_replace_transition.rs
• packages/wasm-dpp/test/integration/identity/stateTransition/IdentityUpdateTransition/validation/state/validateIdentityUpdateTransitionStateFactory.spec.js
• packages/rs-dpp/src/state_transition/state_transitions/document/documents_batch_transition/document_transition/mod.rs
• packages/wallet-lib/src/plugins/Workers/TransactionsSyncWorker/TransactionsReader.spec.js
• packages/wallet-lib/src/plugins/Workers/TransactionsSyncWorker/TransactionsSyncWorker.spec.js
• packages/wasm-dpp/test/integration/identity/stateTransition/assetLockProof/chain/validateChainAssetLockProofStructureFactory.spec.js

• packages/js-dash-sdk/src/SDK/Client/Platform/Fetcher/Fetcher.ts
• packages/js-dapi-client/lib/test/fixtures/getMetadataFixture.js
• packages/js-dapi-client/lib/methods/platform/getStatus/TimeStatus.js
• packages/wasm-dpp/src/document/state_transition/document_batch_transition/document_transition/document_create_transition.rs

• GitHub Check: Rust packages (wasm-dpp) / Tests
• GitHub Check: Rust packages (drive-abci) / Tests
• GitHub Check: Rust packages (drive-abci) / Check each feature
• GitHub Check: Rust packages (drive-abci) / Linting
• GitHub Check: Rust packages (dpp) / Check each feature
• GitHub Check: Rust packages (dash-sdk) / Check each feature
• GitHub Check: Rust packages (drive) / Tests
• GitHub Check: Build Docker images (Drive, drive, drive-abci) / Build Drive image
• GitHub Check: Build Docker images (Dashmate helper, dashmate-helper, dashmate-helper) / Build Dashmate helper image
• GitHub Check: Build Docker images (DAPI, dapi, dapi) / Build DAPI image
• GitHub Check: Build JS packages / Build JS

packages/wasm-dpp/src/identity/state_transition/identity_update_transition/identity_update_transition.rs (2)

179-181: LGTM! Clean function signature.

The simplified function signature without the explicit unit return type follows Rust best practices.

---

438-440: LGTM! Appropriate type upgrade.

The change from u32 to u64 for the revision value aligns with the PR's objective to handle larger numeric values.

packages/js-dash-sdk/src/SDK/Client/Platform/methods/contracts/history.spec.ts (1)

59-63: LGTM! Correct implementation of BigInt for uint64 values.

The changes correctly implement the new response structure using BigInt for uint64 values, which aligns with the PR objectives to prevent precision loss.

packages/wasm-dpp/src/identity/state_transition/identity_credit_transfer_transition/transition.rs (4)

92-100: LGTM! Correct type change for amount handling.

The change from f64 to u64 for amount handling is appropriate and aligns with the PR objectives to prevent precision loss when dealing with uint64 values.

---

102-105: LGTM! Improved encapsulation.

The change to use the accessor method improves encapsulation while maintaining the correct type.

---

117-120: LGTM! Simplified method signature.

The removal of the unnecessary unit return type annotation improves code clarity while maintaining the correct type for nonce.

---

181-185: LGTM! Correct BigInt serialization for JavaScript interop.

The use of JsValue::bigint_from_str ensures that uint64 values are correctly represented as BigInt in JavaScript, preventing precision loss. The implementation is consistent across both toObject and toJSON methods.

Also applies to: 256-260

packages/wasm-dpp/src/document/state_transition/document_batch_transition/document_transition/document_delete_transition.rs (1)

87-93: LGTM! Removing explicit unit return type aligns with Rust idioms.

The change to remove the explicit -> () return type is a good cleanup that follows Rust's idiomatic style where unit return types are typically implicit.

Verify uint64 handling aligns with PR objectives.

Since this PR aims to fix uint64 handling using BigInt for better precision, please verify that using raw u64 type here is intentional and doesn't need to be adjusted for the WASM boundary.

Run this script to check how other uint64 fields are handled in the WASM bindings:

✅ Verification successful

🏁 Script executed:

#!/bin/bash
# Search for uint64/u64 handling patterns in WASM bindings
rg -A 5 "u64|uint64" "packages/wasm-dpp/src/"

Length of output: 64423

---

Review Summary: Raw u64 Usage Consistent and Intentional

• The removal of the explicit unit return type aligns with Rust idioms.
• The raw u64 type for identity contract nonce is used consistently across similar document transition methods (e.g., in document_create_transition and document_replace_transition).
• WASM conversion utilities (such as try_to_u64 in src/utils.rs) handle BigInt conversions externally, ensuring the boundary is correctly managed while the internal representation remains u64.

No changes are needed here.

packages/js-dapi-client/lib/methods/platform/getStatus/ChainStatus.js (5)

35-40: LGTM!

The method is well-documented and correctly implemented.

---

42-54: LGTM!

The block hash getter methods are well-documented and correctly implemented.

Also applies to: 63-75

---

91-96: LGTM! Correct JSDoc return type.

The implementation correctly specifies number|null as the return type, as previously suggested.

---

99-99: LGTM!

The module export is correctly implemented.

---

56-61: LGTM! Correctly using BigInt for block heights.

The implementation aligns with the PR objective to use BigInt for uint64 values, ensuring precise handling of large numbers.

Let's verify the consistent use of BigInt across the codebase:

Also applies to: 77-89

✅ Verification successful

🏁 Script executed:

#!/bin/bash
# Description: Check for consistent use of BigInt type for block heights
# Test: Search for block height related fields and their types
rg -A 2 'blockHeight|BlockHeight' --type js --type ts

Length of output: 66464

---

Block Height BigInt Usage Verified

The search output confirms that in our client code (and corresponding tests) block height values are handled as BigInt, including in the ChainStatus getters. The unit tests in packages/js-dapi-client for GetStatusResponse consistently compare these values using BigInt, verifying that our implementation meets the PR objectives.

packages/js-dash-sdk/src/SDK/Client/Client.ts (1)

166-170: LGTM! Code cleanup improves readability.

The refactoring simplifies the implementation by directly returning the result of this.wallet.getAccount. While this change improves code quality, it doesn't directly contribute to the PR's objective of fixing u64 handling.

Note that this method might need to be updated if any of its dependencies (like Account.Options or the wallet's getAccount method) have been modified to handle u64 values as BigInt. Run this script to verify:

✅ Verification successful

🏁 Script executed:

#!/bin/bash
# Description: Check if Account.Options or getAccount method signatures have been updated for BigInt support

# Search for Account.Options type definition changes
rg -A 5 "interface.*Options.*Account" packages/js-dash-sdk/src/

# Search for getAccount method signature changes in wallet-lib
rg -A 5 "getAccount.*" packages/@dashevo/wallet-lib/

Length of output: 190

---

Let's gather more detailed information. We need to verify the method signature of getAccount and the Account.Options definition. Since the initial script produced no output and indicated that the wallet-lib directory doesn't exist at the expected path, we'll run new shell scripts to search the repository for any wallet-lib directories and occurrences of getAccount as well as Account.Options definitions.

---

🏁 Script executed:

#!/bin/bash
# Script to further search for wallet-lib directories, and occurrences of getAccount and Account.Options in the repository

echo "Listing directories that match 'wallet-lib':"
fd -t d "wallet-lib"

echo "Searching for 'getAccount' function usage in the repository:"
rg -n "getAccount\s*\(" .

echo "Searching for interface definitions related to Account Options (which might indicate BigInt handling):"
rg -n -A 5 "interface.*Options.*Account" .

Length of output: 8233

---

LGTM! Code cleanup improves readability.

The updated implementation in the Client’s getWalletAccount method now directly returns the result of wallet.getAccount with the available options without any intermediate processing. Our additional search confirms that neither the Account.Options interface nor the getAccount method signature in wallet-lib has been updated for BigInt/u64 handling.

Thus, while the cleanup streamlines the code, it doesn’t modify any u64-related functionality. If the PR’s primary objective is to fix u64 handling by replacing number with BigInt, please ensure that the underlying wallet logic or type definitions are updated accordingly elsewhere in the codebase.

• Reviewed file: packages/js-dash-sdk/src/SDK/Client/Client.ts (lines 166–170)
• Confirmed that getAccount in wallet-lib still showcases the same signature with Account.Options unchanged.

packages/wasm-dpp/test/integration/identity/IdentityFacade.spec.js (4)

35-35: LGTM! Proper BigInt usage for balance.

The change to use BigInt(0) instead of 0 aligns with the PR's objective to handle uint64 values correctly.

---

176-176: LGTM! Proper BigInt usage for revision increment.

The explicit use of BigInt(1) ensures correct handling of the revision value.

---

184-184: LGTM! Proper BigInt arithmetic.

The change to use BigInt addition (+ BigInt(1)) ensures type consistency when performing arithmetic operations with BigInt values.

---

38-81: Consider adding test cases for BigInt handling.

While the BigInt changes are tested in the update transition test, consider adding test cases to verify:

• Edge cases with large uint64 values
• Proper handling of BigInt in validation
• Error cases for non-BigInt values

Would you like me to help generate additional test cases for these scenarios?

🧰 Tools

🪛 Biome (1.9.4)

[error] 65-65: This variable is used before its declaration.

The variable is declared here:

(lint/correctness/noInvalidUseBeforeDeclaration)

packages/js-dapi-client/lib/BlockHeadersProvider/BlockHeadersProvider.js (4)

8-8: LGTM! Documentation improvements.

The typedef changes improve clarity by adding explicit string quotes and documenting the fromBlockHeight property.

Note that these changes appear unrelated to the PR's primary objective of fixing uint64 handling. Please confirm if additional type changes are needed here to support the uint64 improvements.

Also applies to: 11-11

---

39-41: LGTM! Clearer parameter descriptions.

The JSDoc comments now provide more explicit descriptions for each constructor parameter.

---

64-64: Consider adding uint64 type annotations.

While the JSDoc improvements enhance clarity, consider adding explicit type annotations for uint64 fields to align with the PR's objective of fixing uint64 handling.

Please confirm if any of these parameters (particularly block heights) should be annotated as BigInt to support the uint64 improvements mentioned in the PR objectives.

Also applies to: 72-72, 108-109, 126-126, 139-140, 200-201

---

142-142: Consider BigInt for block heights.

Given that block heights are handled as numbers throughout the implementation (e.g., in readHistorical), there might be precision issues if these values exceed JavaScript's safe integer limits. Consider using BigInt for block heights to align with the PR's uint64 handling improvements.

Please verify if block heights in the blockchain context can exceed Number.MAX_SAFE_INTEGER. If so, consider:

1. Converting block height parameters to BigInt
2. Updating the implementation to handle BigInt values
3. Adding runtime checks for safe integer limits

Also applies to: 154-156

✅ Verification successful

🌐 Web query:

What is the maximum possible block height in a blockchain and can it exceed JavaScript's MAX_SAFE_INTEGER?

💡 Result:

Blockchain block height has no inherent maximum limit and can theoretically grow indefinitely as new blocks are added[1][6][10]. However, JavaScript's `Number.MAX_SAFE_INTEGER` (9,007,199,254,740,991) imposes technical constraints when handling these values in standard JavaScript code[2][5][8].

## Key Analysis
**Blockchain Block Height Mechanics**
- Block height counts blocks since the genesis block (height 0)[1][6]
- Bitcoin adds ~144 blocks/day (~52k/year)[1][7]
- Current Bitcoin height example: ~882k blocks[4]
- No protocol-level ceiling exists – grows indefinitely with network activity[1][10]

**JavaScript Limitations**
- Safe integer limit: \(2^{53} - 1 = 9,\!007,\!199,\!254,\!740,\!991\)[2][5][8]
- Exceeding this causes precision loss:
  ```javascript
  console.log(9007199254740992 === 9007199254740993); // true[5]
  ```
- Bitcoin would reach MAX_SAFE_INTEGER in ~17 million years at current rate

**Practical Implications**  
| Scenario | Handling Requirement |
|----------|----------------------|
| Below MAX_SAFE_INTEGER | Standard JS numbers work |
| Above MAX_SAFE_INTEGER | Requires BigInt type[3][8] |

```javascript
// Safe handling with BigInt
const currentHeight = 882163n; // BigInt literal
const futureHeight = currentHeight + 1000000000000000n; // Valid[3][8]
```

## Critical Blockchain Events vs JS Limits
- **Bitcoin halvings** occur every 210k blocks (~4 years)[4]
- **Difficulty adjustments** every 2k blocks (~2 weeks)[4]
- These intervals remain safely below MAX_SAFE_INTEGER for millennia

While blockchain heights could theoretically surpass JavaScript's safe integer limit over extremely long timescales[1][7], modern implementations using BigInt avoid precision issues[3][8]. Protocol designs like Bitcoin's halving schedule ensure critical network events remain computable within standard number ranges for centuries[4].

Citations:

- 1: https://www.investopedia.com/terms/b/block-height.asp
- 2: https://www.w3schools.com/jsref/jsref_max_safe_integer.asp
- 3: https://javascript.plainenglish.io/going-big-with-javascript-numbers-71616cac8e44?gi=c7c1595cbc3f
- 4: https://learnmeabitcoin.com/technical/blockchain/height/
- 5: https://stackabuse.com/bytes/maximum-and-minimum-values-for-integers-in-javascript/
- 6: https://tatum.io/blog/blockchain-blocks
- 7: https://newhedge.io/bitcoin/block-height
- 8: https://docs.vultr.com/javascript/standard-library/Number/MAX_SAFE_INTEGER
- 9: https://docs.ethers.org/v5/single-page/
- 10: https://www.bitdegree.org/crypto/learn/crypto-terms/what-is-block-height

---

BigInt Consideration for Block Heights

Our web research confirms that while current blockchain block heights (such as Bitcoin's) are significantly below JavaScript's Number.MAX_SAFE_INTEGER, there is no inherent protocol limit. Block heights can theoretically grow indefinitely and may eventually exceed Number.MAX_SAFE_INTEGER. Although this scenario is extremely remote, handling block heights as BigInt in functions like readHistorical future-proofs the code against potential precision issues.

• Verify that block height values are properly converted to or handled as BigInt when approaching or exceeding the safe integer limit.
• Consider updating the implementation in packages/js-dapi-client/lib/BlockHeadersProvider/BlockHeadersProvider.js (lines 142 and 154-156) for consistency in handling uint64 values.

Reviewing files that changed from the base of the PR and between 6cf9e43 and f417e1f.

• packages/dapi-grpc/clients/platform/v0/nodejs/platform_protoc.js (89 hunks)
• packages/dapi-grpc/clients/platform/v0/web/platform_pb.d.ts (38 hunks)
• packages/dapi-grpc/clients/platform/v0/web/platform_pb.js (89 hunks)
• packages/dapi-grpc/protos/platform/v0/platform.proto (18 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getIdentityKeys/getIdentityKeysFactory.spec.js (2 hunks)
• packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_transition.rs (1 hunks)

• packages/js-dapi-client/test/unit/methods/platform/getIdentityKeys/getIdentityKeysFactory.spec.js

• GitHub Check: Rust packages (drive-abci) / Unused dependencies
• GitHub Check: Rust packages (drive-abci) / Tests
• GitHub Check: Rust packages (drive-abci) / Linting
• GitHub Check: Rust packages (drive-abci) / Formatting
• GitHub Check: Rust packages (drive-abci) / Check each feature
• GitHub Check: Rust packages (drive) / Unused dependencies
• GitHub Check: Rust packages (drive) / Tests
• GitHub Check: Rust packages (drive) / Linting
• GitHub Check: Rust packages (dpp) / Unused dependencies
• GitHub Check: Rust packages (dpp) / Tests
• GitHub Check: Rust packages (dpp) / Linting
• GitHub Check: Rust packages (dpp) / Check each feature
• GitHub Check: Rust packages (dash-sdk) / Unused dependencies
• GitHub Check: Rust packages (dash-sdk) / Tests
• GitHub Check: Rust packages (dash-sdk) / Linting
• GitHub Check: Rust packages (dash-sdk) / Check each feature
• GitHub Check: Rust packages (dapi-grpc) / Unused dependencies
• GitHub Check: Rust packages (dapi-grpc) / Tests
• GitHub Check: Rust packages (dapi-grpc) / Linting
• GitHub Check: Rust packages (dapi-grpc) / Check each feature

packages/dapi-grpc/clients/platform/v0/nodejs/platform_protoc.js (9)

6731-6731: LGTM! Consistent handling of uint64 fields in ResponseMetadata.

The changes correctly implement string-based handling of uint64 fields (height and timeMs) in the ResponseMetadata class, including serialization, deserialization, and accessor methods.

Also applies to: 6734-6734, 6774-6775, 6786-6787, 6827-6830, 6848-6851, 6873-6876, 6881-6885, 6927-6930, 6935-6939

---

9975-9975: LGTM! Consistent handling of uint64 fields in Identity-related responses.

The changes correctly implement string-based handling of uint64 fields (identityNonce, identityContractNonce, and balance) in the identity-related response classes, including serialization, deserialization, and accessor methods.

Also applies to: 10015-10016, 10057-10061, 10085-10088, 10093-10096, 10427-10427, 10467-10468, 10509-10513, 10537-10540, 10545-10548, 10879-10879, 10919-10920, 10961-10965, 10989-10992, 10997-11000

---

11473-11474: LGTM! Consistent handling of uint64 fields in BalanceAndRevision.

The changes correctly implement string-based handling of uint64 fields (balance and revision) in the BalanceAndRevision class, including serialization, deserialization, and accessor methods.

Also applies to: 11512-11517, 11549-11560, 11567-11570, 11575-11579, 11585-11588, 11593-11597

---

16062-16062: LGTM! Consistent handling of uint64 fields in Vote and Identity Balance responses.

The changes correctly implement string-based handling of uint64 fields (count and balance) in the vote and identity balance related response classes, including serialization, deserialization, and accessor methods.

Also applies to: 16104-16105, 16144-16148, 16197-16200, 16205-16209, 16819-16819, 16861-16862, 17900-17905, 17954-17957, 17962-17965

---

23318-23318: LGTM! Consistent handling of uint64 fields in DataContract responses.

The changes correctly implement string-based handling of uint64 fields (startAtMs and date) in the data contract related response classes, including serialization, deserialization, and accessor methods.

Also applies to: 23371-23372, 23431-23435, 23565-23568, 23573-23577, 23975-23975, 24014-24015, 24051-24055, 24069-24072, 24077-24081

---

45220-45222: LGTM! Consistent handling of uint64 fields in Time-related responses.

The changes correctly implement string-based handling of uint64 fields (local, block, and genesis) in the time-related response classes, including serialization, deserialization, and accessor methods.

Also applies to: 45261-45270, 45306-45324, 45338-45341, 45346-45350, 45356-45359, 45364-45367, 45392-45395, 45400-45403

---

45723-45723: LGTM! Consistent handling of uint64 fields in Chain Status responses.

The changes correctly implement string-based handling of uint64 fields (latestBlockHeight, earliestBlockHeight, and maxPeerBlockHeight) in the chain status response classes, including serialization, deserialization, and accessor methods.

Also applies to: 45726-45727, 45778-45779, 45790-45795, 45852-45856, 45873-45884, 46000-46003, 46008-46012, 46102-46105, 46110-46114, 46120-46123, 46128-46132

---

46394-46395: LGTM! Consistent handling of uint64 fields in StateSync responses.

The changes correctly implement string-based handling of uint64 fields (time-related fields, block counts, and sync statistics) in the state sync response classes, including serialization, deserialization, and accessor methods.

Also applies to: 46397-46401, 46439-46468, 46500-46553, 46560-46563, 46568-46572, 46578-46581, 46586-46590, 46614-46617, 46622-46626, 46632-46635, 46640-46644, 46650-46653, 46658-46662, 46668-46671, 46676-46680, 46686-46689, 46694-46698

---

6731-46698:

❓ Verification inconclusive

Verify the impact of uint64 to string conversion.

The changes consistently implement string-based handling of uint64 fields across all response classes. This aligns with the PR objective to fix precision loss issues. However, we should verify:

1. That all consumers of these APIs are updated to handle string values
2. That the string values are properly converted to BigInt where needed

Run the following script to find potential consumers that might need updates:

---

🏁 Script executed:

#!/bin/bash
# Description: Find potential API consumers that might need updates

# Search for direct usage of the getter methods
rg -l "get(Height|TimeMs|IdentityNonce|Balance|Count|StartTime|BlockHeight)" --type js

# Search for comparisons that might assume number type
rg "===?\s*0" --type js

Length of output: 33354

---

Ensure Consumers Correctly Handle uint64 as Strings and Convert Precisely When Needed

The PR now uniformly converts uint64 fields to strings to avoid precision loss, and our verification shows that many consumers (for example, in packages/dapi-grpc/clients/platform/v0/nodejs/platform_protoc.js) are already performing numeric checks—often using constructs like if (parseInt(f, 10) !== 0). This suggests that consumers expect a string return and are converting these values on demand.

Please double-check the following:

• Consumer Compatibility: Confirm that all API consumers (including those in client libraries and tests) correctly handle string representations instead of raw numbers.
• Precision in Conversions: Ensure that any numeric operations requiring high precision use proper conversion to BigInt rather than relying solely on parseInt, which might be insufficient for extremely large values.

Overall, the approach aligns with the PR’s objective, but a closer manual review of numeric conversion paths in critical areas is recommended.

packages/dapi-grpc/clients/platform/v0/web/platform_pb.js (5)

6731-6731: LGTM! Proper handling of uint64 values in ResponseMetadata.

The conversion of height and timeMs fields to string type in ResponseMetadata will prevent precision loss for large uint64 values.

Also applies to: 6734-6734

---

9975-9975: LGTM! Proper handling of uint64 values in identity-related responses.

The conversion of identityNonce, identityContractNonce, and balance fields to string type in identity-related responses will prevent precision loss for large uint64 values.

Also applies to: 10427-10427, 10879-10879

---

45720-45728: LGTM! Proper handling of uint64 values in chain status fields.

The conversion of block height fields (latestBlockHeight, earliestBlockHeight, maxPeerBlockHeight) to string type will prevent precision loss for large uint64 values.

---

34813-34817: LGTM! Proper handling of uint64 values in vote-related responses.

The conversion of timestamp fields to string type in vote-related responses will prevent precision loss for large uint64 values.

Also applies to: 34852-34857

---

46394-46401: LGTM! Proper handling of uint64 values in state sync fields.

The conversion of time and block count fields to string type in state sync responses will prevent precision loss for large uint64 values.

packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_transition.rs (2)

1-296: LGTM! Well-structured implementation following Rust best practices.

The code demonstrates:

• Proper error handling with Option types
• Clean trait implementations
• Consistent pattern matching
• Clear documentation

---

181-190:

❓ Verification inconclusive

Verify if the entropy method changes are intentional.

The changes appear to be formatting-only for the None cases, but the implementation still returns Some(Vec::from(t.entropy())) for the Create variant. This seems unrelated to the PR's main objective of fixing uint64 handling.

Let's verify if there are any related changes in other files:

---

🏁 Script executed:

#!/bin/bash
# Description: Search for other entropy-related changes and uint64 handling in the codebase.

# Search for entropy method implementations
ast-grep --pattern 'fn entropy($$$)'

# Search for uint64 type usage
rg -A 5 'uint64|u64'

Length of output: 89735

---

Action Required: Confirm the Intent Behind the Entropy Method Changes

The updated implementation in
packages/rs-dpp/src/state_transition/state_transitions/document/batch_transition/batched_transition/document_transition.rs
now returns entropy only for the Create variant while all other match arms explicitly return None. Our search confirmed that related entropy methods (e.g., in the v0_methods file) use a different return type ([u8; 32] vs. Option<Vec<u8>>), and the recent uint64-related updates elsewhere in the repository do not directly affect this method.

• The refactoring appears to adjust only the formatting and explicit None returns without introducing new logic.
• Since the PR mainly targets uint64 handling, please verify that these formatting changes in the entropy method were indeed intended and not an unintended side effect.

Please confirm if this update is deliberate or if further modifications are required.

packages/dapi-grpc/clients/platform/v0/web/platform_pb.d.ts (4)

58-59: LGTM! Proper handling of uint64 values.

The conversion of height and timeMs fields from number to string type in ResponseMetadata ensures proper handling of uint64 values without precision loss.

Also applies to: 67-68, 88-88, 91-91

---

537-538: LGTM! Consistent handling of uint64 values in identity-related fields.

The conversion of nonce and balance fields from number to string type in identity-related messages ensures consistent handling of uint64 values.

Also applies to: 563-563, 606-607, 632-632, 675-676, 701-701

---

703-704: LGTM! Consistent handling of uint64 values in time and epoch-related fields.

The conversion of time, epoch, and balance-related fields from number to string type ensures proper handling of uint64 values.

Also applies to: 776-777, 779-780, 794-795, 4066-4067, 4090-4091, 4084-4085, 4108-4109

---

1447-1448: LGTM! Comprehensive handling of uint64 values in block and state-related fields.

The conversion of block heights, counts, and sync-related fields from number to string type completes the consistent handling of uint64 values across the codebase.

Also applies to: 1463-1463, 4734-4735, 4762-4763, 5861-5862, 5864-5865, 5873-5874, 5876-5877, 5879-5880, 5882-5883

packages/dapi-grpc/protos/platform/v0/platform.proto (4)

83-86: LGTM! Proper handling of large integers.

The addition of [jstype = JS_STRING] to height and time_ms fields ensures accurate representation of large integers in JavaScript, preventing potential precision loss.

---

178-191: LGTM! Critical fields properly handled.

The addition of [jstype = JS_STRING] to nonce, balance, and revision fields ensures accurate handling of these critical values in JavaScript, particularly important for:

• Identity nonce used in transaction submission
• Balance values that could exceed JavaScript's integer precision
• Revision numbers for versioning

Also applies to: 204-218, 390-390

---

766-768: LGTM! Consistent handling of temporal and block-related fields.

The addition of [jstype = JS_STRING] to epoch, timestamp, and block height fields ensures consistent and accurate handling of these values across the platform.

Also applies to: 829-833, 852-852, 912-914

---

1159-1203:

✅ Verification successful

LGTM! Comprehensive coverage of status metrics.

The addition of [jstype = JS_STRING] to all status-related uint64 fields ensures accurate representation of:

• Local and block timestamps
• Block heights
• Sync metrics and durations

Let's verify that all uint64 fields have been properly updated:

---

🏁 Script executed:

#!/bin/bash
# Description: Check for any uint64 fields that might be missing the jstype option

# Search for uint64 fields without jstype
rg "uint64\s+\w+\s*=\s*\d+\s*(?!.*jstype.*JS_STRING)" -P

# Search for uint64 fields with jstype for comparison
rg "uint64.*jstype\s*=\s*JS_STRING" --count

Length of output: 9968

---

LGTM! All status-related uint64 fields now consistently use [jstype = JS_STRING].

The changes in the Chain and StateSync messages (as well as the related status fields in the snippet) correctly annotate metrics such as block heights, timestamps, and sync durations. Verification with the grep script confirms that every uint64 field in these status messages has the [jstype = JS_STRING] option applied.

Note: Other uint64 fields (like those for token balance, amount, or timestamps outside the status context) remain unannotated. This appears to be intentional since they are expected to stay within safe numeric ranges.

Reviewing files that changed from the base of the PR and between f417e1f and 7b40975.

• packages/dapi/lib/externalApis/drive/fetchProofForStateTransitionFactory.js (1 hunks)
• packages/dapi/test/unit/externalApis/drive/fetchProofForStateTransitionFactory.spec.js (2 hunks)
• packages/js-dapi-client/lib/methods/platform/getIdentityKeys/GetIdentityKeysResponse.js (2 hunks)
• packages/js-dapi-client/test/unit/methods/platform/getIdentityKeys/getIdentityKeysFactory.spec.js (4 hunks)
• packages/wasm-dpp/test/integration/document/DocumentFacade.spec.js (2 hunks)

• packages/dapi/lib/externalApis/drive/fetchProofForStateTransitionFactory.js

• GitHub Check: Rust packages (drive-abci) / Unused dependencies
• GitHub Check: Rust packages (rs-dapi-client) / Check each feature
• GitHub Check: Rust packages (drive-abci) / Tests
• GitHub Check: Rust packages (drive-abci) / Linting
• GitHub Check: Rust packages (drive-abci) / Formatting
• GitHub Check: Rust packages (drive-abci) / Check each feature
• GitHub Check: Rust packages (drive) / Unused dependencies
• GitHub Check: Rust packages (drive) / Tests
• GitHub Check: Rust packages (drive) / Linting
• GitHub Check: Rust packages (dpp) / Tests
• GitHub Check: Rust packages (dpp) / Unused dependencies
• GitHub Check: Rust packages (dash-sdk) / Tests
• GitHub Check: Rust packages (dash-sdk) / Linting
• GitHub Check: Rust packages (dash-sdk) / Check each feature
• GitHub Check: Build Docker images (DAPI, dapi, dapi) / Build DAPI image
• GitHub Check: Build Docker images (Dashmate helper, dashmate-helper, dashmate-helper) / Build Dashmate helper image
• GitHub Check: Build JS packages / Build JS

packages/wasm-dpp/test/integration/document/DocumentFacade.spec.js (5)

11-11: LGTM: Class rename is consistent with the PR changes.

The rename from DocumentsBatchTransition to BatchTransition maintains functionality while improving naming clarity.

---

98-98: LGTM: Test description updated to match class rename.

The test description has been updated to reflect the new class name, maintaining consistency.

---

106-106: LGTM: Contract ID now uses string format.

Converting the contract ID to string format aligns with the PR's objective of properly handling uint64 values to prevent precision loss.

---

110-110: LGTM: Instance check updated for renamed class.

The instance check has been updated to use the new class name BatchTransition.

---

111-114: Consider uncommenting and updating the commented test expectations.

The commented-out expectations might be valuable for thorough testing. Consider either:

1. Uncommenting and updating them to work with the new changes
2. Removing them if they're no longer relevant

packages/js-dapi-client/lib/methods/platform/getIdentityKeys/GetIdentityKeysResponse.js (2)

5-14: LGTM! Type annotation updated correctly.

The JSDoc update from number to Buffer[] for the identityKeys parameter aligns with the PR's objective to improve type handling.

---

16-21: LGTM! Return type annotation updated consistently.

The JSDoc update from number to Buffer[] for the return type maintains consistency with the constructor parameter type.

packages/js-dapi-client/test/unit/methods/platform/getIdentityKeys/getIdentityKeysFactory.spec.js (1)

107-114: LGTM! Proper handling of uint64 values using BigInt.

The metadata assertions have been correctly updated to handle uint64 values (height and timeMs) using BigInt, while maintaining direct comparisons for other fields. This aligns with the PR's objective to fix precision issues with uint64 values.

packages/dapi/test/unit/externalApis/drive/fetchProofForStateTransitionFactory.spec.js (1)

12-15: LGTM!

The import changes properly introduce the DocumentTransition class, aligning with the PR's goal of improving type safety.